home *** CD-ROM | disk | FTP | other *** search
- Date: Fri, 29 Jul 1994 00:46:13 -0400 (EDT)
- From: Timothy Miller <millert@cs.csee.usf.edu>
- Subject: Amodal Dialogs
- To: gem-list@world.std.com
- In-Reply-To: <memo.804849@cix.compulink.co.uk>
- Message-Id: <Pine.3.87.9407290013.C17722-0100000@grad>
- Mime-Version: 1.0
- Precedence: bulk
-
-
- Hollis:
-
- ]Whoever (Gee, I like anonymous messages):
- ]-----------------------------------------
- ]> No, it is NOT that simple. When you click to top a window, the message
- ]> does not get sent until you let go of the button. You can hold the
- ]> button all day, and the window won't get topped until you let go of the
- ]> button.
- ]
- ]Have you even TRIED doing what I've proposed? Sure, the message may not
- ]be sent until you let go of the mouse button, but you can surely trap it.
- ]Have you *tried* doing this?
- ]
- ]Oh, and I hate to tell you... *YES IT IS THAT SIMPLE*
-
- YES! I have tried it! I've been doing it ever since the first time
- someone mentioned this as a technique for taking clicks for background
- windows.
-
- And I very much like to tell you: *NO IT IS NOT THAT SIMPLE*
-
- And here's why.....
-
-
- To everyone:
-
- I figured out how to do drags and the like for background windows, and
- I'm surprised I didn't think of it earlier. Earlier today, I made the
- above comment about the WM_TOPPED event not getting to the window until
- after the button is released. This is not correct.
-
- It appears that evnt_multi will not return to the program for the NEXT
- evnt_multi if the mouse button is still held down -- OR -- event_multi
- will not continue to send WM_TOPPED messages for the window clicked on
- while the button is still held down.
-
- Now knowing this, I had a background window that I had flagged as
- untoppable and background active (using flags in my program... I'm using
- regular TOS, so there is no WF_BEVENT). When the WM_TOPPED message would
- come to my program, I would get the mouse position and pass the correct
- information to the routine that handles mouse events for the dialog.
- This worked fine, except that if I PRESSED the mouse button (rather than
- clicking it), then the program would no longer get any more WM_TOPPED
- messages for that window until I clicked somewhere outside of that window.
-
- This frustrated me, so I tried a few solutions. First, I put a simple
- loop after the mouse-event routine came back to wait until the button was
- let up before returning. This did not help.
-
- Then I tried putting that loop BEFORE the call to the mouse-event
- routine. This caused clicks to be sent only after the mouse was let up,
- but it solved the problem of the window not getting any more WM_TOPPED
- messages.
-
- It was at that point that I realised that if I were to continue to
- simulate mouse events as long as the button was held down, then I
- wouldn't have to worry about evnt_multi not returning... I wouldn't be
- using evnt_multi until after the button had been let up.
-
- This worked great. I could drag sliders and everything.
-
- But there is a problem with form_button and objects marked as
- selectable. As you know, when a selectable button is clicked,
- form_button does not return until the button is let up. What I want to
- know is how is the use of form_button when a button is PRESSED (not
- simply clicked) preventing further WM_TOPPED messages from being sent to
- my application for that window, and how do I solve this problem?
-
- Everything would be just dandy if something weren't preventing these
- WM_TOPPED messages from being sent. Other messages seem to get sent just
- fine, and the problem clears up if I click anywhere outside of the window
- in question... until I press a button again.
-
-
- Ta.
-
-
-